(19) 



(12) 



(43) Date of publication: 

15.04.1998 Bulletin 1998/16 



Europaisches Patentamt 
European Patent Office 
Off ice europeen des brevets (11) EP 0 836 306 A1 

EUROPEAN PATENT APPLICATION 

(51) int. CI. 6 : H04L 29/06, H04Q 1 1/04 



(21) Application number: 96410106.7 

(22) Date of filing: 10.10.1996 



(84) 


Designated Contracting States: 


• Terrasse, Denis 




AT BE CH DE DK ES Fl FR GB GR IE IT LI LU MC 


38320 Eybens (FR) 




NL PT SE 






Designated Extension States: 


(74) Representative: 




AL LT LV SI 


Squibbs, Robert Francis 






Intellectual Property Section, 


(71) 


Applicant: 


Legal Department, 




Hewlett-Packard Company 


Hewlett-Packard France, 




Palo Alto, California 94304 (US) 


Etablissements de Grenoble 






F-38053 Grenoble Cedex 9 (FR) 


(72) 


Inventors: 




Sasyan, Serge 


Remarks: 




381 70 Seysstnet (FR) 


The application is published incomplete as filed 


• 


Roger, Denis 


(Article 93 (2) EPC). A claim No.7 is missing. 




38760 Varces (FR) 





(54) System providing for multiple virtual circuits between two network entities 



(57) Computers sending IP datagrams over an ATM 
network are generally capable of operating multiple 
simultaneous virtual circuits over the network. However, 
in doing so, they normally only set up one virtual circuit 
to each destination IP address so that in order to test 
the simultaneous operation of N virtual circuits by a 
computer under test, N target computers are needed. 
To enable a single computer (T) to provide the destina- 
tion endpoints for multiple virtual circuits (SVC) from a 
computer (M) under test, both computers (M.T) are allo- 



cated a plurality of virtual IP addresses (iM(j).lT(i)) ^ 
the target computer (T) is additionally provided with a 
module running address-changing processes (70,71) 
that avoids the IP layers (20) of both computers from 
rejecting IP datagrams (25A.25B) addressed with the 
virtual IP addresses. As a result, each computer (M,T) 
can be addressed with any of a plurality of IP addresses 
and each will result in the creation of a respective virtual 
circuit (SVC) between the computers (M,T). 
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Description 

Field of the Invention 

The present invention relates to a system providing 
for multiple virtual circuits between two network entities 
for use in particular, but not exclusively, in the testing of 
network node apparatus providing IP messaging over 
an ATM network. 

Background of the Invention 



w 



As is well-known, the Internet Protocol (IP) uses a 
scheme of IP addresses by which every connection of a 
node to the Internet has a unique IP address. IP 15 
addresses are high-level addresses in the sense that 
they are independent of the technology used for the 
underlying network to which a node is connected. Each 
node will also have a low-level, network-dependent 
address .(often callled the MAC address) that is actually 20 
used for addressing at the network level and the IP pro- 
tocol suite includes a address reolution protocol (ARP), 
logically positioned below the IP layer itself, that is 
responsible for translating between IP addresses con- 
tained in a message and the local MAC addresses. 25 

An increasingly important technology for local area 
networks is ATM. ATM (Asynchronous Transfer Mode) is 
a multiplexing and switching technique for transferring 
data across a network using fixed sized cells that are 
synchronous in the sense that they appear strictly peri- 30 
odically on the physical medium. Each cell comprises a 
payload portion and a header, the latter including a label 
that associates the cell with an instance of communica- 
tion between sending and receiving network end sys- 
tems; this instance of communication may involve the 35 
transfer of many cells from the sending end system, 
possibly to multiple receiving end systems. ATM is asyn- 
chronous in the sense that cells belonging to the same 
instance of communication will not necessarily appear 
at periodic intervals. <*o 

In ATM, the labels appended to the cells are fixed- 
size context dependent labels, that is, they are only 
understandable in the light of context information 
already established at the interpreting network node, 
the label generally being replaced at one node by the 45 
label required for the next node. In other words, ATM is 
a virtual circuit technology requiring a set up phase for 
each instance of communication to establish the appro- 
priate label knowledge at each node. Of course, to set 
up a desired communication, it is still necessary to iden- so 
tify uniquely the nodes forming the communication end 
points and this is achieved by using ATM addresses, 
generally of a significance limited to the particular ATM 
network concerned. 

The process of sending IP messages (datagrams) 55 
over a ATM network, including the operation of the 
required ATM ARP system, is set out in RFC 1577 of the 
IETF internet Engineering Task Force) dated January 



1993. This RFC assumes an arrangement in which a 
sending node will only establish a single vircuit circuit to 
a given destination IP address (of course, this one vir- 
cuit circuit may carry multiple connections between 
respective pairings of high-level end points in the 
nodes). 

Figure 1 of the accompanying drawings is a dia- 
gram illustrating the basic mechanism by which two 
machines M and T exchange IP datagrams over a 
switched virtual circuit (SVC) established across an 
ATM network The machines M and T have respective 
IP addresses ! M and l T and respective ATM addresses 
A M and Ay, each machine knows its own addresses. An 
ATMARP server S knows the IP and ATM addresses of 
all active nodes on the network, including machines M 
and T; more particularly, server S maintains an ARP 
table 15 associating the IP address of each node with its 
ATM address. The server S maintains open a respective 
SVC (switched virtual circuit) to each active node and 
the identity of this SVC is held in the ARP table 15; thus, 
in the Figure 1 example, the server S is in communica- 
tion with machine M over an SVC identified as SVC "1" 
at the server, and the server S is in communication with 
machine T over an SVC identified as SVC "2" at the 
server S. At machines M and T these virtual circuits are 
independently identified - thus at machine M its SVC to 
the server S is identified as SVC "3" whilst at machine T 
its SVC to the server S is identified as SVC "5". 

The communications interface 18 in each of the 
machines M and T comprises three main layers, 
namely: an IP layer 20 responsible for forming IP data- 
grams (including source and destination IP addresses) 
for transmission ad for filtering incoming datagrams; an 
intermediate IP/ATM layer 21 for determining the SVC 
corresponding to the destination IP address of an out- 
going datagram; and an ATM layer 22, including the low- 
level network interface hardwarej for sending and 
receiving datagrams packaged in ATM cells over SVCs. 

The IP/ATMlayer 21 maintains an ARP cache table 
27 which like the table 15 of the server S contains asso- 
ciations between IP address, ATM address and SVC. 
Thus, table 27 of machine M contains an entry of the IP 
address l s , ATM address A s , and SVC identity "3" for 
the server S, and similarly, table 27 of machine T con- 
tains an entry of the IP address l s , ATM address A s , and 
SVC identity "5" for the server S. The cache table 27 
only holds information relevant to current SVCs of the 
machine concerned so that during the initial establish- 
ment of a SVC to a new destination, the cache table 
must be updated with relevant information from the 
ATMARP server S; this general process will be 
described in more detail hereinafter with reference to 
Figure 2. For the present, it will be assumed that an 
SVC has already been established between machines 
M and T and that the cache tables contain the relevant 
information (in particular, cache table 27 of machine M 
contains an entry with the IP address l T . ATM address 
Ay, and SVC identity "4" for machine T, and cache table 



iNSOOCID: <EP 0Q363O6AT I > 



3 



EP 0 836 306 A1 



4 



27 of machine T contains an entry with the IP address 
l M , ATM address A M , and SVC identity "9" for machine 
M). 

Considering now the case of a high-level applica- 
tion in machine M wanting to send a message to 
machine T, this application passes the message to the 
IP layer 20 together with the destination IP address l T . 
IP layer 20 packages the message in one (or more) dat- 
agrams 25A with a destination IP address of l T and 
source l P address of l M . Datagram 25A is then passed 
to the IP/ ATM layer 21 which executes an IP-to-SVC 
lookup task 30 to determine from table 27 the SVC to be 
used for sending the datagram to its destination address 
l T ; in the present case, table 27 returns the SVC identity 
"4" and the layer 21 passes this identity together with 
the datagram 25A to the ATM layer 22 which then sends 
the datagram in ATM cells on SVC "4". The datagram is 
in due course received by machine T and passed up by 
layers 22 and 21 to the IP layer 20 where a filtering task 
29 determines from the datagram destination address 
that the datagram is indeed intended for machine T; the 
contents of the datagram are then passed to the rele- 
vant high-level application, in the present example, this 
high-level application produces a reply message which 
it passes to the IP layer 20 together with the required 
return address, namely the source IP address in the 
received datagram 25A. IP layer 20 generates datagram 
25B with the received return address as the destination 
address, the IP address l T of machine T being included 
as the source address. The datagram 25B is passed to 
IP/ATM layer 21 where IP-to-SVC lookup task 30 deter- 
mines from cache table 27 that the required destination 
can be reached over SVC "9". This information together 
with datagram 25B is then passed to ATM layer 22 
which transmits the datagram in ATM cells over SVC "9" 
to machine M. When the datagram is received at 
machine M it is passed up to the IP layer 20 where it is 
filtered by task 29 and its contents then passed on to the 
relevant high-levei application. 

Figure 2 of the accompanying drawings illustrates 
in more detail the functioning of the IP/ATM layers 21 of 
machines M and T in respect of datagram transmission 
from machine M to machine T it being appreciated that 
the roles of the two layers 21 are reversed for transmis- 
sion in the opposite direction. More particularly, upon 
the IP-to-SVC lookup task 30 being requested to send a 
datagram to IP address l T , it first carries out a check of 
the cache table 27 (step 31) to determine if there is an 
existing entry for l T (and thus an SVC, assuming that 
entries are only maintained whilst an SVC exists). Step 
32 checks the result of this lookup - if an SVC already 
exists (in this case, SVC "4"), then step 39 is executed 
in which the datagram is passed together with the iden- 
tity of the relevant SVC to the ATM layer 22; however, if 
the lookup was unsuccessful, task 30 executes steps 33 
to 38 to set up an SVC to destination l T before executing 
step 39. 

The first step 33 of the setup process involves the 



sending of an ARP request to the ATMARP server S 
over the relevant SVC requesting the ATM address cor- 
responding to l T . Server responds with ATM address Ay 
which is received by task 30 at step 34. 

5 Task 30 now updates the cache table 27 with the IP 

address l T and ATM address Aq- (step 35). Next, task 30 
requests (step 36) the ATM layer 22 to establish a new 
SVC to ATM address A r and this initiates an SVC setup 
process 28 which may be executed in any appropriate 

w manner and will not be described in detail herein. In due 
course, process 28 returns the identity of the SVC that 
has been set up to Ay (in this case, SVC n 4") t this iden- 
tity being received at step 37 of task 30. Finally, cache 
table 30 is updated at step 38 by adding the SVC iden- 

75 tity ("4") to the entry already containing l T and Af. 

In machine T, the setup of the new SVC to the 
machine from machine M is handled by the setup proc- 
ess 28 of machine T The process 28 informs the 
IP/ ATM layer that a new SVC has been setup and this 

20 triggers execution of an update task 40 to update the 
cache table 27 of machine T More particularly, on the 
new SVC indication being received (step 41), a first 
update step 42 is carried out to add an entry to the table 
confining the identity of the new SVC (in the present 

25 example "9"), and the ATM address A M of the node at 
the other end of the SVC; at this stage, the correspond- 
ing IP address is not known to machine T. In order to 
obtain this IP address, an inverse ARP request is now 
made to machine M (step 43). In due course a response 

30 is received (step 44) containing the IP address of 
machine M. The cache table 27 is then updated at step 
45 with the IP address l M of machine M and the IP/ATM 
layer is now ready to effect IP-to-SVC translations for 
datagrams intended for machine M. 

35 The inverse ARP request sent, by machine T to 
machine M is handled by an inverse ARP task 50 that 
examines the request (step 51) and on finding that it 
contains the ATM address A M , responds with the IP 
address l M of machine M (step 52). 

40 To facilitate explanation of the preferred embodi- 
ment of the invention hereinafter, the messages across 
the boundary between the IP/ATM layer 21 and the ATM 
layer 22 have been labelled in Figure 2 as follows where 
superscript "T" indicates an outgoing message (that is, 

45 from the IP/ATM layer to the ATM layer) and the super- 
script "R M indicates incoming messages (that is, from 
the ATM layer to the IP/ATM layer): 

X1 T - outgoing ARP request; 

so X2 R - incoming ARP response; 

X3 T - outgoing SVC setup request; 

X4 R - incoming SVC setup done indication; 

X5 R - incoming new SVC indication; 

X6 T - outgoing INARP request; 

55 X6 R - incoming INARP request; 

X7 T - outgoing INARP response; 

X8 T - outgoing datagram; 

X8 R - incoming datagram. 



X1 T - 
50 X2 R - 
X3 T - 
X4 R - 
X5 R - 
X6 T - 
55 X6 R - 
X7 T - 
X8 T - 
X8 R - 
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It will be appreciated that machines connecting to 
an ATM network, such as machines M and T as well as 
the server S, are designed to handle a large number of 
virtual circuits simultanteously. If in testing such a 
machine (machine M in the following discussion) it is 5 
desired to fully stress the machine under test, then the 
design limit of concurrently operating virtual circuits 
must be simultaneously used. However, as already indi- 
cated, current practice is that only one virtual circuit is 
established to each distinct IP address. As a result, 10 
since generally each machine that might be used to test 
machine M has only one network connection and there- 
fore only one IP address, if machine M is designed to 
operate up to N virtual circuits simultaneously, then it 
requires N machines to test machine M. Such an 75 
arrangement is illustrated in Figure 3 where the N 
machines are constituted by the server S and (N-1) 
other machines here represented as machines T1 to 
T(N-1). Such an arrangement is generally impractical as 
N may be as high as 1 024 or more. 20 

It is an object of the present invention to provide a 
mechanism that enables, inter alia, the foregoing test 
problem to be overcome. 

Summary of the Invention 25 

According to the present invention, there is pro- 
vided a system in which a plurality of entities are con- 
nected to a network ad can exchange messages across 
virtual circuits set up over the network between said 30 
entities, each entity having a operative high-level 
address on the network, and each entity comprising: 

-- high-level messaging means for handling mes- 
sage transmission and receipt on the basis of the 35 
aforesaid high-level addresses, the high-level mes- 
saging means comprising means for including in 
outgoing messages the operative high-level 
address of the entity as a source identifier and the 
operative high level address of the intended recipi- 40 
ent entity as a destination identifier, and means for . 
filtering incoming messages according to the desti- 
nation identifier contained in the message: 
- virtual-circuit means for providing virtual circuits 
between the entity and other entities, there being a 45 
respective virtual circuit for each different destina- 
tion identifier in use, and 

-- intermediate means for passing an outgoing mes- 
sage from the high-level messaging means to that 
one of the virtual circuits provided by the virtual -cir- so 
cuit means which corresponds to the destination 
identifier of the message; 

characterised in that each of a first and a second one 
of the entities has a plurality of virtual high-level 55 
addresses associated with it that are different from the 
operative high-level address of the entity, the virtual 
high-level addresses being usable by the messaging 



means of the first and second entities as destination 
identifiers in outgoing messages; and in that between 
the intermediate means of the first and second entities, 
there are provided address-changing means respon- 
sive to each of at least some of the messages sent 
between these entities with a said virtual high-level 
address as its destination identifier, to change that 
address to the operative high-level address of the corre- 
sponding entity and to change the operative high-level 
address provided as the source identifier of the mes- 
sage into one of the said virtual high-level addresses 
associated with the sending entity in dependence on the 
virtual high-level address initially provided as the desti- 
nation identifier of the same message. 

By virtue of this arrangement, it is possible to estab- 
lish a plurality of virtual circuits between the first and 
second entities by using the different virtual high-level 
addresses of the entities as the destination identifiers in 
messages exchanged between the entities, the receiv- 
ing high-level adressing means accepting such mes- 
sages due to the address-changing means having 
changed the destination identifier to the operative high- 
level address of the receiving entity. By also changing 
the source identifier, it is possible to retain in the mes- 
sage information sufficient to associate any reply mes- 
sage with a particular one of the virtual circuits 
established with the sending entity (in particular, the 
reply message can be sent back over the same virtual 
circuit as the message to which it is a reply - however, if 
desired, it is also possible to use a separate virtual cir- 
cuit for the reply messages). 

Preferably, the address-changing means comprises 
first address-changing functionality for effecting the 
aforesaid changes for messages sent from the first 
entity to the second entity, and second address-chang- 
ing functionality for effecting these changes for mes- 
sages sent from the second entity to the first entity, both 
the first and second address-changing functionalities 
being provided in the second entity. This configuration is 
well suited for testing the ability of network node appa- 
ratus to concurrently operate a plurality of virtual circuits 
where the network node apparatus is operative to 
establish a virtual circuit for each different high-level 
destination address being handled; more particularly, 
the network node apparatus serves as the aforesaid 
first entity, and is caused to send messages to at least 
some of the vial high-level addresses associated with 
the second entity. By placing the address-changing 
means in the second entity, no modifications are 
needed to the network node apparatus in order for it to 
be able to establish a plularity of virtual circuits with the 
second entity. 

Advantageously, the address-changing means 
effects a predetermined transformation on the virtual 
high-level address forming the initial destination identi- 
fier of a said message in order to form the virtual high- 
level address to be used for the source identifier of that 
message. For example, this transformation may simply 
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involved changing the address by one (where the 
address is numeric in form). 

The present invention is particularly applicable to 
systems in which the high-level addresses are IP 
addresses and the network is an ATM network. 5 

Brief Description of the Drawings 

A system embodying the invention will now be 
described, by way of non-limiting example, with refer- w 
ence to the accompanying diagrammatic drawings, in 
which: 

. Figure 1 is a diagram of a known system for send- 
ing IP datagrams over a ATM network is 
between two machines M and T; 

. Figure 2 is a diagram illustrating the steps carried 
out by the Figure 1 system in establishing 
a virtual circuit between machines M and 
T; 20. 

. Figure 3 is a diagram of a known test arrangement 
for testing the ability of a machine M to 
concurrently operate multiple virtual cir- 
cuits; 

. Figure 4 is a diagram showing a test arrangement 25 
embodying the invention for testing the 
ability of a machine M to concurrently addresses 
operate multiple virtual circuits; 

. Figure 5 is a diagram similar to Figure 1 but show- 
ing a system embodying the invention in 30 
which multiple virtual circuits are estab- 
lished between machines M and T; 

. Figure 6 is a diagram illustrating the processing 
effected by a module VNS disposed in 
machine T of the Figure 5 system when 35 
machine M initiates the opening of a new 
virtual circuit between machines M and 
T; and 

. Figure 7 is a diagram illustrating the processing 

effected by a module VNS disposed in 40 
machine T of the Figure 5 system when 
machine T initiates the opening of a new 
virtual circuit between machines M and T 

Best Mode of Carrying Out the Invention 4s 

The embodiment of the invention now to be 
described provides a system in which it is possible to 
establish a plurality of SVCs (switched virtual circuits) 
across an ATM network for the exchange of IP data- so 
grams between two machines M and T whereby it is 
possible to test the ability of machine M to concurrently 
operate a plurality of virtual circuits without needing to 
provide a respective destination machine for each SVC 
operated by machine M. The overall test arrangement is ss 
illustrated in Figure 4 where machine M operates N 
SVCs over ATM network 10, one SVC being with 
ATMARP server S and (N-1) SVCs being with machine 



T According to the preferred embodiment, the estab- 
lishment of multiple concurrent SVCs between machine 
M and T is effected without modification to machine M. 

Figure 5 shows a system embodying the present 
invention, this system being similar to that of Figure 1 
but being operative to provide a plurality of concurrent 
SVCs 65 between machines M and T In the Figure 5 
system, the machines M and T and the server S are 
assumed to operate in the same way and have the 
same IP and ATM addresses as in Figure 1 ; in addition, 
in Figure 5 the same SVCs are established between the 
server S and the machines M and T as in Figure 1 . The 
Figure 5 system includes, however, added functionality 
provided by processes 70 and 71 which in Figure 5 are 
shown independent of machines M and T but in practice 
would be provided either distributed between machines 
M and T or wholly in one of these machines; in a pre- 
ferred embodiment, the processes 70 and 71 are pro- 
vided in machine T 

In accordance with the present invention, each 
machine M and T is allocated a number of virtual IP 
addresses different from its operative (or "real") IP 
address (this latter address being the one which the IP 
layer knows about for inclusion as the source address in 
outgoing datagrams and upon which filtering is carried 
out by task 29). Thus, machine M is allocated virtual IP 



'M(1)- 'M(2)- 



allocated virtual IP addresses \ T ^ t l T ( 2 ) I 



•'m(]) similarly, machine T is 

T(i)- 



Each of these virtual IP addresses is entered into 
table 1 5 of ATMARP server S together with the ATM 
address of the corresponding one of the machines M,T; 
thus virtual IP address I M q) is associated with ATM 
address A M and virtual IP address l T(j) is associated 
with ATM address Af. 

Now, if the communications interface 1 8 of machine 



M is asked to send a message to IP address I 



T(i). 



IP 



layer 20 will construct a datagram 25A having a destina- 
tion address of and a source address of l M . The IP- 
to-SVC task 30 of IP/ATM layer 21 then acts in the man- 
ner already described to fetch the ATM address corre- 
sponding to l T (j) from server S and set up an SVC (here 
identified by "p") towards machine T; the cache table 27 
is updated appropriately. The datagram 25A is now sent 
by ATM layer over SVC(p) to machine T 

If no further action is taken, the datagram 25A, after 
receipt at machine T, will be rejected by the filter task 29 
as the destination address l T ^ of the datagram differs 
from the operative IP address l T known to task 29 of 
machine T. Accordingly, a process 70 is provided that 
recognises the destination address of datagram 25A as 
being a virtual IP address of machine T and substitutes 
the real IP address of machine T for the virtual address 
in the destination field of the datagram 25A. The data- 
gram will now be allowed through by filter task 29 of 
machine T. 

However, a further difficultly remains. If only the 
destination address is changed, the resultant datagram 
contains no indication that the datagram was not ordi- 
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narily sent with the real IP address of machine T; any 
reply will therefore be sent on an SVC set up to take dat- 
agrams from machine M to the real IP address of 
machine M. This SVC would end up taking ail the reply 
messages for messages sent from machine M to 5 
machine T over all the SVCs set up in respect of the vir- 
tual IP addresses allocated to machine T. This is clearly 
undesirable. To avoid this, the source address of data- 
gram 25A is also changed by process 70. More particu- 
larly, the source address is changed from the real IP w 
address of machine M to one of the virtual IP addresses 
l M (j) of this machine, the virtual address chosen being 
dependent on the original virtual IP address forming the 
destination address of the datagram. As a result, all dat- 
agrams 25A having the same virtual destination 75 
address end up after operation of process 70 as data- 
grams 25AA with the same virtual source address, 
whereas datagrams 25A having different initial virtual 
destination addresses end up as datagrams 25AA with 
different source addresses. The process of changing 20 
the source address preferably involves a predetermined 
transformation of the virtual destination address - for 
example, to obtain the required virtual source address, 
the virtual destination address can simply be incre- 
mented by one (there would thus exist, for example, a 25 
set of even virtual IP addresses for machine M and a 
corresponding set of odd virtual IP addresses for 
machine T, each even virtual IP address of machine M 
being associated with the immediately adjacent, lower- 
valued, odd virtual IP address of machine T). 30 

The address-changing process 70 must be carried 
out on datagram 25 A after operation of the IP-to-SVC 
task 30 in machine M and prior to the filter task 29 in 
machine T In addition, whilst the two address-hanging 
operations of process 70 need not be carried out at the 35 
same time or at the same location (though it is, of 
course, convenient to do so), the changing of the source 
address must be done whilst the initial virtual destina- 
tion address is still available. 

The contents of datagram 25 AA are passed by IP 40 
layer 20 of machine T to a high-level application which, 
in the present example, produces a reply that it passes 
to layer 20 for sending back to IP address l M (j), that is, to 
the source address contained in datagram 25AA. Layer 
20 produces a datagram 25B with source address lj 45 
and destination address Next, IP-to-SVC task 30 of 
layer 21 looks up the destination address in the cache 
table 27 to find out the SVC to be used for the reply. If, 
as will normally be the case, the same SVC is to be 
used for the reply as carried the original datagram 25A so 
with destination address l T(i) , then the SVC setup proc- 
ess will have been arranged to enter the address l M ^ in 
cache table 27 against that SVC (in present case, iden- 
tified to machine T by "q"); a lookup on l M Q) will thus 
return "q" as the required SVC. However, if it is desired 55 
to use a different SVC for datagrams 25B passing from 
T to M as used for datagrams 25A passing from M to T, 
then the first lookup on l M{j) by task 30 will not identify an 



SVC and task 30 must then initiate set up of a new SVC. 

Assuming that the same SVC is to be used for the 
datagrams 25B with destination address l M( j) as for the 
datagrams 25A with destination address l T (j). then alter 
task 30 has identified SVC(q) as the appropriate SVC, 
the datagram 25B is passed to the ATM layer 22 for 
sending out over SVC(q). In due course, machine M 
receives this datagram and passes it up to IP layer 20; 
however, before the datagram reaches this layer, it must 
undergo address-change processing similar to that car- 
ried out on datagram 25A. More particularly, the virtual 
destination address l M( j) must be changed to the real IP 
address l^ of machine M, and the real source address 
l T of machine T must be changed to the virtual IP 
address of machine T associated with the virtual 
destination address l M (j)- This address-change process- 
ing is carried out by process 71 . 

With regard to the source address change, where 
the corresponding change was effected for datagram 
25A by incrementing by one the virtual destination 
address l T(j) of that datagram, then for datagram 25B, 
the source address is changed to the destination 
address decremented by one. 

In a similar manner to process 70, process 71 must 
be carried out on datagram 25B after operation of the 
IP-to-SVC task 30 in machine T and prior to the filter 
task 29 in machine M. In addition, whilst the two 
address-changing operations of process 71 need not be 
carried out at the same time or at the same location, the 
changing of the source address must be done whilst the 
initial virtual destination address is still available. 

Following operation of process 71, datagram 25BB 
with source address l T (j) and destination address l M is 
allowed through by filter task 29 and the contents of the 
datagram are passed to the relevant high-level applica- 
tion. 

Having described the general mechanism by which 
virtual IP addresses can be used for exchanging data- 
grams 25A and 25B across a SVC between machines 
M and T, the issue will now be addressed as to how the 
cache table 27 in machine T is updated on SVC setup to 
associate the new SVC (that is, SVC(q) at machine T) 
with the virtual IP address I M q) of machine M (this is 
required where the same SVC is to be used for the reply 
datagram 25B as for the original datagram 25A). It will 
be appreciated that when the task 40 (see Figure 2) is 
executed, the INARP request sent to machine M will 
only return the real IP address l M of machine M, there 
being no other information available to the update task 
40 by which any other result could be obtained from the 
INARP task 50; clearly, something additonal needs to 
be done for update task 40 to be able to associate the 
virtual IP address l M (j) with the newly created SVC(q) in 
table 27. In fact, there are a number of ways in which the 
update task could be informed that the IP address to be 
associated with SVC(q) is l M(j ). For example, the update 
task 40 could be arranged to send a request back over 
the newly-created SVC(q) asking machine M to identify 
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the destination IP address l T(i) it associates with that 
SVC; from this information, the update task could deter- 
mine the associated virtual IP address l M (j) of machine 
M (assuming there is a predetermined relation between 
the two as is the case in the described embodiment) 
and then update table 27 accordingly. An alternative 
approach that avoids sending a special request to 
machine M is to wait for machine M to supply the desti- 
nation IP address l T(i) in the first IP datagram 25A sent 
over the new SVC(q). the update task then deriving the 
required address as described above. 

A variant of this latter approach is to leave the 
update task 40 unchanged but provide an additional 
process that: 

(a) delays the INARP request until the destination 
address l T (,) of the first datagram from machine M 
to machine T can be captured; 

(b) uses the captured address l T(j) as the source 
address of the INARP request that is now sent on to 
machine M. 

The INARP response from machine M will therefore 
have a destination address l-r(j) and a source address 
(that forms the substance of the INARP response) of l M . 
By ensuring that this response datagram is subject to 
the processing effected by process 70, the source data 
in the INARP response will be changed to l M (j) by the 
time the response reaches the update task 40. Thus, 
the required updating of the table 27 of machine T can 
be achieved without modification to the existing tasks of 
machines M and T but simply by the addition of a further 
process for effecting steps (a) and (b) described above. 
This approach is the preferred one for updating table 27 
and is the one used in the module described below with 
reference to Figures 6 and 7. 

The above-described system involving the alloca- 
tion of multiple virtual IP addresses to machines M and 
T and the provision of the address-changing processes 
70 and 71 , permits multiple SVCs to be concurrently 
operated between the machines M and T thereby ena- 
bling implementation of the test arrangement depicted 
in Figure 4. Of course, when testing the machine M, it is 
desirable that no changes are made to this machine; 
accordingly, it is preferred for such a test arrangement to 
implement the address-changing processes 70 and 71 
in machine T. 

The implementation of the address-changing proc- 
esses 70 and 71 , and of the INARP request modification 
process^ can conveniently by done by inserting a mod- 
-ule (hereinafter called the VNS module) between the 
IP/ATM layer 21 and the ATM layer 22 of machine T; in 
fact, an instance of this module is created for each SVC, 
this being relatively easy to implement when using a 
STREAMS type I/O implementation as provided in most 
UNIX systems (conveniently one stream is provided for 
each SVC and the VNS module is pushed onto each 
stream when the stream is created). 



The messages passing across the boundary 
between layers 21 and 22 have already been described 
above with reference to Figure 2 and the processing 
effected by the VNS module on each of these messages 

s will next be described. First, the situation of Figure 5 will 
be considered where it is machine M that initiates the 
setting up of a new SVC to machine T The first mes- 
sage received by the VNS module will be the SVC setup 
indication message X5 R and this is passed through the 

w VNS module without modification (see Figure 6). Next, 
the INARP request X6 T is received and is subject to the 
modification process 82 described above, namely it is 
delayed until the first IP datagram 25A is received and 
the address l T (j) extracted and used for the source 

is address of the INARP request. The INARP response 
X7 R is then received and subject to the address-chang- 
ing process 70. IP datagrams X8 R from machine M to 
machine T are also subject to the address-changing 
process 70. IP datagrams X8 T from machine T to 

20 machine M are subject to address-changing process 
71. 

Figure 7 depicts the processing effected by the 
VNS module in the situation where it is the machine T 
rather than the machine M that initiates SVC setup. The 
25 messages passing through the VNS module in this case 
are those shown crossing the boundary between layers 
21 and 22 in Figure 2 for machine M. The first four mes- 
sages X1 T , X3 T , X2 R , and X4 R are passed through with- 
out modification. The INARP request received from 
30 machine M is subject to the modification process 82, 
being delayed until the destination address of the first IP 
datagram from machine T to machine M can be cap- 
tured and used as the source address of the INARP 
request. The INARP response X7 T is subjected to proo- 
fs ess 71 as are IP datagrams X8 T from machine T to 
machine M. IP datagrams X8 R from machine M to 
machine T are subjected to process 70. 

It will be appreciated that many variants are possi- 
ble to the above-described embodiment of the irrven- 
40 tion. It will also be appreciated that the invention is not 
limited to switched virtual circuits but can equally be 
applied to permanent virtual circuits. Furthermore, the 
setting up of multiple virtual circuits between two 
machines can be used not only for implementing the 
45 test arrangement described above with reference to Fig- 
ure 4 but also for other purposes. 

Although the present invention has been described 
in the context of high-level addresses constituted by IP 
addresses and virtual circuits set up across an ATM net- 
so work, the invention can be applied to other types high- 
level addresses and other types of virtual-circuit net- 
work. For example, the high-level addresses could be 
MAC addresses in the case of a network in the form of 
a emulated LAN (ELAN) over an ATM network. 

55 

Claims 

1. A system in which a plurality of entities are con- 
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nected to a network and can exchange messages 
across virtual circuits set up over the network 
between said entities, each entity having an opera- 
tive high-level address on the network, and each 
said entity comprising: 5 

- high-level messaging means for handling 
message transmission and receipt on the basts 
of said high-level addresses, said high-level 
messaging means comprising means for 10 
including in outgoing ones of said messages 
the operative high-level address of the entity as 
a source identifier and the operative high level 
address of the intended recipient entity as a 
destination identifier, and means for filtering 15 
incoming ones of said messages according to 
the destination identifier contained in the mes- 
sage: 

~ virtual-circuit means for providing virtual cir- 
cuits between the entity and other said entities, 20 
there being a respective virtual circuit for each 
different destination identifier in use, and 

intermediate means for passing an outgoing 
message from said high-level messaging 
means to that one of the virtual circuits pro- 25 
vided by the virtual-circuit means which corre- 
sponds to the destination identifier of the 
message; 

characterised in that each of a first and a second 30 
said entity has a plurality of virtual high-level 
addresses associated with it that are different from 
said operative high-level address of the entity, said 
virtual high-level addresses being usable by the 
messaging means of said first and second entities 35 
as destination identifiers in outgoing messages; 
and in that between said intermediate means of 
said first and second entities, there are provided 
address-changing means responsive to each of at 
least some of said messages sent between these 40 
entities with a said virtual high-level address as its 
destination identifier to change that address to the 
said operative high-level address of the corre- 
sponding entity, and to change the operative high- 
level address provided as the source identifier of 45 
the message into one of the said virtual high-level 
addresses associated with the sending entity in 
dependence on the virtual high-level address ini- 
tially provided as the destination identifier of the 
same message. so 

2. A system according to claim 1, wherein said 
address-changing means effects a predetermined 
transformation on the virtual high-level address 
forming the initial destination identifier of a said 55 
message to which the address-hanging means is 
responsive in order to form the virtual high-level 
address to be used for the source identifier of that 



message. 

3. A system according to claim 2, wherein said 
address-changing means is responsive to mes- 
sages sent in both directions between said first and 
second entities with virtual high-level addresses as 
destination identifiers, the said transformation 
effected in respect of such messages sent in one 
said direction being the reverse of the transforma- 
tion effected in respect of other such messages 
sent in the opposite said direction. 

4. A system according to claim 1, wherein said 
address-changing means comprises first address- 
changing functionality for effecting said changes for 
messages sent from said first entity to said second 
entity, and second address-changing functionality 
for effecting said changes for messages sent from 
said second entity to said first entity both said first 
and second address-changing functionalities being 
provided in said second entity. 

5. A system according to claim 1, wherein said 
address-changing means comprises first address- 
changing functionality for effecting said changes for 
messages sent from said first entity to said second 
entity, and second address-changing functionality 
for effecting said changes for messages sent from 
said second entity to said first entity, the two said 
address-changing functionalities being provided in 
respective ones of said first and second entities. 

6. A system according to claim 1 , wherein: 

- each said entity has a low-level address on 
the network; 

- said intermediate means of each entity fur- 
ther comprises: 

~ first association means for providing an 
association between the destination identi- 
fier of a outgoing message and the low- 
level address of the corresponding said 
entity, 

- second association means for providing 
an association between the destination 
identifier of an outgoing message and a 
said virtual circuit, 

said intermediate means using its second 
association means to identify from the destina- 
tion identifier of a said outgoing message which 
virtual circuit is to be passed the message 
where such virtual circuit exists, and otherwise 
first passing a request to the said virtual circuit 
means of the same entity to establish a virtual 
circuit to the entity having the low-level address 
identified by said first association means as 
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associated with the destination identifier of the 
outgoing message; and 

- the said virtual-circuit means of each entity 
includes setup means responsive to a said 
request from the intermediate means of the s 
same entity to establish a virtual circuit to the 
said entity having the low-level address pro- 
vided in said request, said setup means caus- 
ing the intermediate means to update its 
second association means to associate the w 
newly-established virtual circuit with the said 
destination identifier relevant to said request; 

the first association means of each of said first and 
second entities serving to provide an association is 
between the virtual high-level addresses of the 
other of said first and second entities and the low- 
level address of that other entity. 

8. A system according to claim 7, further compris- 20 
ing a network server containing associations 
between high-level addresses and low-level 
addresses, said first association means of each 
said entity comprising means for interrogating said 
network server for a required association. 25 

9. A system according to claim 7, wherein said sec- 
ond association means comprises cache means for 
temporarily holding said associations between said 
destination identifiers and currently corresponding 30 
virtual circuits. 

1 0. A system according to any one of claims 1 to 9, 
wherein said high-level addresses are IP addresses 
and said network is a ATM network. 35 

11. A system according to any one of claims 1 to 9, 
wherein said high-level addresses are MAC 
addresses and said network is a emulated LAN 
over an ATM network. <*o 

12. A method of testing the ability of network node 
apparatus to operate a plurality of virtual circuits at 
the same time, said network node apparatus being 
arranged to establish a virtual circuit for each differ- 45 
ent high-level destination address being handled, 
said method involving setting up a system accord- 
ing to claim 4 with said network node apparatus as 
said first entity, and causing the network node 
apparatus to send messages to at least some of so 
said virtual high-level addresses associated with 
said second entity. 
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